退款这么做，就没有退不回去的钱

退款是一个比较常见的逆向业务

但是退款不是说什么时候想退就能退，不同的渠道不同类型的支付有不同的退款时效

过了退款时效，还能把钱退出去么？或者说，过了退款时效，怎么样才能把钱退回去呢？

渠道的退款时效是渠道开放给商户的权益，而商户和用户的退款协议是另一回事，二者难免存在错配

比如，某平台就是敢承诺，永久可退，那么我想没有任何一个支付渠道可以满足他这个诉求，怎么办？

产品经理的神奇魔力就是，交给他，啥事都能给你办，不就是把超退款时效的款退回去么

既然原渠道退不了了，那么......就得整点幺蛾子了

退款的本质就是“把钱给他”，真想退，那就打破原路退的禁锢

支付的逆向是退款，而退款也有几种基础的模式，我们先把这个了解清楚

怎么退

一笔订单的内容构成是多样化的，那么也必然造成一笔退款的构成也是多样化的

订单包含多个商家，多款商品，多种费用，那么退款的花样就多了

从退款的基础能力上来说，一般的渠道会提供以下几种退款模式，我们可以把每一种退款模式当成一种退款产品

对于平台来说，又可以基于渠道的基础退款模式，封装出更多场景的退款产品

比如，可以将按商品退封装出一个按“商家退”的模式，将一个订单中的同一个商家的商品打包进行退款，从效果上就是按商家退

这种处理手段，就是产品经理在设计上的灵活性；没有出路，也要基于手头的能力创造出新出路

从哪里出钱

钱不一定都在一个篮子里，那退款也就不一定从一个账户往回退

退款的本质也不是必须原路退款到指定账户，而是将钱从收款者手里退回付款者手里

那么，对于收款者来说，就没必要必须从收款的账户出

在渠道签约产品时，往往会开通多个账户，比如基本户、运营账户、手续费账户、营销账户等，都属于该商户

而同一个账户也可能有多种资金属性，比如可用余额、冻结余额、待结算余额等

所以，在退款时，有的渠道会提供指定出款账户和资金类型的能力

当然，对于一个交易体量很大的平台来说，对这一能力并没有太强的诉求，从原基本户退回足够了

退回哪里

前面我们讲了，退款的本质是退给付款的人，而不一定非得是付款的账户

因为付款人在该平台可能有多个收款路径，比如在微信有绑定的银行卡、也有微信零钱，如果原路退回绑定的卡失败，那么微信可以决定退回用户的零钱账户

这样我们就把退款的基础能力梳理清楚了

开头介绍了，退款有退款时效，过了这个时效，原支付不再支持通过渠道退回

但是，本身的业务存在这样的超时效退款场景，比如平台的退款协议就是比渠道的退款时效长

比如家政行业，有的客户一次签约3年，那么其中的客户服务费就是在三年内可退，当2年半时要退剩下的半年单子，那么服务费就需要退回半年的

这个时候很明显已经过了渠道的退款时效了，但是从业务上来说又必须退款

怎么办

基于退款的本质是退回付款人这一点，我们不难想到——走付款

构建一个新的退款产品——退转付

该退款产品的核心职能就是将超过退款时效的退款申请，转换成付款，将钱付给付款人

要想实现这一退款产品能力，还有几件重要的事情要做，毕竟你要打破常规

打破常规，往往需要更高的成本

将退款转为付款的第一个难题就来了，钱付到哪里？

因为原渠道退回本身就有一个隐藏属性，那就是我们知道用户用哪个账户付的款，渠道就会退回这个已知的账户

但是，付款给用户，难度就大了，因为我们不一定知道用户的收款账户信息

将退款业务转换成付款要做的第一件事就是“采集用户的收款账户信息”

如此，就将第一个难题转换成了一个可落地的需求，采集用户收款信息

有了目标，实现起来就容易多了

可以客户人工采集银行卡信息

也可以在用户订单中心增加一个提示：已超原路退款的时效，需要您提交银行卡信息，平台将在3个工作日以内将款项打到该卡中

以上的问题就变成了“采集入口”问题

一个真正的产品难题会被一层层的分解，直到找到了答案，产品设计的过程其实就是这样一个过程

那么怎么发起上述的采集动作呢？就是当后台点击“退转付”时，当然这个发起动作可以是人为触发，也可以是系统自动触发

当退款失败的原因是“超过退款时效”同时用户退款协议约定又可退时，自动触发该退款路径

当然了，在发起采集时可以先判断平台有没有用户的收款卡信息，如果有的话可以选择合适的付款通道将钱支付出去

触发以后，在原退款订单基础之上生成一笔付款单

该付款单是明确的“退转付”，与原退款单关联，付款类型定义为“退款转付款”

还有非常重要的一个问题需要解决，就是付款与原退款在信息上的强关联，特别是状态的联动

为什么

因为退款业务是受到原支付单强制性限制，就是总退款金额不能超过原支付金额，而且，退款付的付款发起的前提是原退款单失败是由于超时效了

如果退转付的付款业务不受上述条件的强制约，那么就可能发生资金损失，产生超额退款

基于上述的控制链，那么退款状态和付款状态之间应该构建起联动性，退转付的状态去更新原退款失败的退款单的状态，原退款单的状态开始了新的流转

最后要说明的是，退转付的付款业务应该归属于“退款”模块，或者说退款业务，而不是付款业务

更精确的描述这个能力，我觉得应该是“基于付款能力的退款产品”

大家可以思考一下这一点

陈天宇宙支付学院

chentianyuzhou.com

你  的  最  强  支  付  军  师

我是你的最强支付军师——陈天宇宙。10年大厂支付产品专家，代表作《支付32真经》《上帝视角看支付》《支付之门》等，为您提供深度支付内容和服务！

扫码访问陈天宇宙支付学院

与110427位小伙伴一起学习